[AWS] Amazon API GatewayでAPI Mockサーバー [作成とGETまで]

#Amazon API Gateway

#AWS

小室啓

2016.01.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。小室です。札幌市はここ数日ようやくまとまった雪が降ってます。 ^*1

いつもの雪より速度が早くてあんまり映らない

こむねこさん(@com4dc)が投稿した動画 - 2016 1月 13 9:34午後 PST

今回はAmazon API Gatewayを利用したAPI Mockサーバーの簡単な作成手順を紹介します。

Amazon API Gateway

スクリーンショット 2016-01-14 11.43.01

Amazon API Gatewayは、APIを簡単に作成することができます。API Gatewayの機能の一つである Mock Integration を利用することで、APIのMockサーバーを簡単に作成できます。

モバイルアプリ開発においては、よくAPIサーバーと同時並行で開発が行われるため、Mockサーバーを構築することがあるかと思います。Mockサーバーから本番サーバーへの切り替えなど、各開発者が苦労して色々と苦労しているかと思います。

Amazon API Gatewayを利用すると、どうやらMockと本番サーバーへの切り替えがコンソール上で簡単にできそうです。なかなか興味深い機能だったので、モバイルアプリケーション用の簡単なAPI Mockサーバーを作成してみます。これを使いこなすとモバイルアプリとAPIサーバーを同時並行で開発する際の強力なツールになるかもしれません（と期待して）

Mock APIを作成する

Amazon API GatewayでAPIを作成します。コンソールからAmazon API Gatewayを選択します。

スクリーンショット 2016-01-18 14.15.26

リージョンは今のところ米国東部（バージニア北部）、米国西部（オレゴン）、EU（アイルランド）、アジア・パシフィック（東京） がサポートされています。

スクリーンショット 2016-01-18 14.15.41

APIを作成

Create API を押すと新たにAPIを作成できます。まずは、APIの名称を決定します。今回は「Sample API」という名称のAPIを作成します。Descriptionは必須ではないので、適当に空でも問題ありません。

スクリーンショット 2016-01-14 15.03.46

APIの作成が完了すると、以下のコンソール画面へ遷移します。Resourceの作成やMethodの作成を行います。

スクリーンショット_2016-01-14_15_03_54

Resourceの作成

APIのパスの階層はResourceとして扱います。今回と次回で以下の2つのAPIを作成してみます。

GET http://hogehoge.com/users : ユーザー情報一覧の取得
GET http://hogehoge.com/users/{id} : ユーザーIDを指定してユーザー情報を取得

今回は1を。

まず users というリソースを作成します。 Create Resource を選択します。

Resource Name はリソースの名称を記載します。「users」をこちらに記載します。

スクリーンショット 2016-01-14 15.04.49

Resource Path はResource Nameを記載すると自動的に作成されます。こちらは基本的にResource Nameと同じものが自動的に補完されますが、特に同じにする必要はありません。実際にAPIでPathとして指定するのは、こちらのResource Pathになります。

今回はResouce Nameと同じ「users」としています。

Create Resource をクリックするとResourceが作成されます。

users というResource Pathが作成されました。

Methodの作成（GET）

続いてMethodを作成します。コンソール左側のペインで /users を選択します。右のペインの Create Method をクリックします。するとResource Path以下に選択肢が現れます。

今回は、/users に対して GET を定義するので、選択肢から「GET」を選択します。

スクリーンショット 2016-01-18 16.41.15

チェックマークをクリックすると、Methodの設定画面へ遷移します。

スクリーンショット 2016-01-14 15.06.23

ここではAPI Gatewayで受けたGETリクエストをキッカケに、どんな処理をキックするかが設定できるようです。選択肢は以下の通りです。

機能	概要
Lambda Function	API Gatewayで受けたリクエストから指定したLambdaを起動させます。
HTTP Proxy	API Gatewayで受けたリクエストを別のHTTPサーバーへリクエストをリダイレクトします。
Mock Integration	API Gatewayで受けたリクエストを受け、Mockレスポンスを返します。
AWS Service Proxy	AWSのサービスを起動できるようです（まだ使ったことない）

今回はMockサーバーを作成するのでMock Integration を選択します。「Save」ボタンをクリックします。

スクリーンショット 2016-01-14 15.06.32

こちらが /users の GET メソッドの動作を定義する設定画面（Method Execution）になります。このコンソールからTest、リクエストのMapping、レスポンスのMappingなどを行うことができます。

Mockの動作を定義する

今回はMockの動作を定義します。設定するのはIntegration Request と Integration Response です。

Integration Request

こちらで、Methodのリクエストの内容を加工することができます。API Gatewayで受けたリクエストはそのまま利用できれば問題ありませんが、インターフェイスが異なる場合は、適宜変換してあげる必要があります。その役割を担うのが Integration Request です。

Integration Request をクリックします。開いた画面で Mapping Templates を展開します。application/json をクリックすると、API Gatewayで受け取ったリクエストをマッピングするためのテンプレートJsonが確認できます。

スクリーンショット 2016-01-14 15.17.23

Mock Integrationを利用する場合は、必ず statusCode の値を入れる必要があります。そのため、こちらの値を削除するとMockの動作はエラーになりますのでご注意ください。

※このMapping Templatesは変更しないほうが良い

{"statusCode": 200}

Method Execution をクリックするとGETの設定画面へ戻ります。

Integration Response

こちらで、Mockから返却するレスポンスを定義します。こちらも前述のIntegration Requestと同じような役割を担っています。API Gatewayで中継された処理は、処理完了後にAPI Gatewayに返却されます。このレスポンスもAPI Gatewayのインターフェイスと合致している保証はありません。そのため、ここで返却値の加工を行うことができます。

Integration Response をクリックします。Mockで返却されるHTTP Statusが200のみ定義されているのが確認できます。Integration Requestとは少し様相が違いますね。Statusコードを複数用意したりする必要がある関係でしょうか。

スクリーンショット 2016-01-18 17.31.35

HTTP Statusコード200の左端にある「▶」をクリックすると Integration Requestと同じく Mapping Templates が確認できます。

ヘッダもMappingによって改変できるようですが、今回はResponseのみ変更しましょう。

Mapping Templates を展開します。Integration Requestと同じく、application/json が定義されているのでこちらをクリックします。

スクリーンショット 2016-01-18 17.53.46

application/json は Output passthrough と設定されているのが確認できます。こちらの設定の場合は、API Gatewayはレスポンスを特に加工せずにそのまま素通りさせます。

今回はMockサーバーとして動作させているため、API Gatewayは特に何の処理も起動していません。そのため、ここでMockとして動作させるデータを定義します。

本来、API Gatewayを通して別のAPIやLambdaを起動した場合、それらのレスポンスはAPI Gatewayの返却値にマッピングしてやる必要があります。返ってきた値がそのままの形で問題ないようであれば、Output passthrough を選択します。

Output passthroughの右にある ペンシルマークをクリックします。すると編集モードになるので、Output passthrough を Mapping template へ変更します。

スクリーンショット 2016-01-18 18.55.38

TemplateにMockのレスポンスとして返却したいデータを定義します。今回は/users に対してのGETメソッドなので、それっぽいJSONの配列データを返すようにします。以下をTemplateに記載し、チェックボタンをクリックします。

[
 {"id": 122, "name": "hoge"},
 {"id": 298, "name": "fuga"}
]

Templateが保存されるので、Saveボタンをクリックします。

スクリーンショット 2016-01-18 18.59.03

これで準備完了です。/users に対するGETメソッドのAPI作成が完了しました。

作成したAPIをテスト

早速テストしてみましょう。APIの道通確認は、コンソールのテスト機能を利用します。Method Execution（つまりは先程から触ってる設定画面）から選択できます。

スクリーンショット 2016-01-18 19.01.23

Test をクリックします。APIのTestを実行する画面へ移動します。

スクリーンショット 2016-01-18 19.02.05

今回は特に認証など設定していないので、Client Certificateの設定は不要です。引数などもないため、そのまま Test ボタンをクリックします。

スクリーンショット 2016-01-18 19.03.24

先ほどIntegration Responseで設定したResponse Templatesが返却されていることが確認できます。正常に実行されたのが確認できました。

Logsには実行時のログが出力されますので、デバッグにとても有効な情報が入っています。Testに失敗した場合などはこちらを確認すると良いかと思います。

まとめ

今回は引数も何もない、単なるGETメソッドに反応するだけのとても単純なMockサーバーを作成してみました。こちらが基本中の基本になります。まだまだ色々と便利そうな機能がたくさんあるようです。次回以降は、URL引数, パラメータ化したパスの扱い、RequestによるResponseの分岐振り分け あたりをコツコツ書いていこうかと思います。